IP networks were originally designed to carry “best effort” traffic where the network makes a “best attempt” to deliver a user packet, but does not guarantee that a user packet will arrive at the destination. Because of the market success of IP networks, there is a clear requirement for mechanisms that allow IP networks to support various types of applications. Some of these applications have Quality of Service (QoS) requirements other than “best effort” service. Examples of such applications include various real time applications (IP Telephony, video conferencing), streaming services (audio or video), or high quality data services (browsing with bounded download delays). Recognizing these QoS requirements, the Internet Engineering Task Force (IETF), which is the main standards body for IP networking, standardized a set of protocols and mechanisms that enable IP network operators to build QoS-enabled IP networks.
FIG. 1 depicts a simplified high-level model of an IP network which may be useful in explaining QoS provisioning. As can be appreciated, the model includes two users, but could easily be expanded to include more users without changing the basic functionality of the network. In FIG. 1, User-A 101 may communicate with User-B 102 or with an application server 103. For example, in the case of an IP telephony session, User-A 101 may communicate with User-B 102. Similarly, in the case of streaming services, User-A 101 may communicate with the application server 103, which may be configured as a video server. In either case, User-A 101 accesses an IP backbone network 104 through a local access network 105, such as PSTN (dial-in access), Global System for Mobile Communications (GSM), or Universal Mobile Telecommunications System (UMTS) network. User-B 102 is similarly connected to the IP network 104 through a local access network 106. It will be appreciated that User-A and User-B need not use the same type of access network. The IP network 104 may consist of a number of IP routers and interconnecting links that together provide connectivity between the IP network's ingress and egress points and thereby make two party communication possible. As far as the users are concerned, the perceived QoS depends on the mechanisms both in the access networks 105, 106 and on the IP backbone network 104. Of particular interest to this invention is the specific case where at least one of the access networks is a UMTS or GSM/GPRS network.
When users access IP-based services, they may use a device that runs an application program that provides the interface for the user to access the particular service. For instance, in FIG. 1, User-A may use a laptop running a conferencing application program to attend an IP network based meeting, where participants of the meeting collaborate using various programs. Such programs are well known in the art.
Various user applications may access network services through an application programming interface (API). An API provides aplication programmers with a uniform interface to access underlying system resources. For instance, an API may be used to configure a network resource manager to require that a particular IP packet originating from a given application receive a certain treatment from the network, such as a particular QoS. For example, if the IP network is a Differentiated Services IP network, then an application program may request that all of its IP packets receive the “Expedited Forwarding” treatment.
The User (and the API in the user's equipment may not be aware of the different technologies that various access networks and IP backbone networks employ in order to provide QoS end-to-end, i.e., from User-A all the way to remote User B. For instance, the application program may use an RSVP/IntServ based API, and the end-to-end embodiment in which he is involved may include a UMTS access network and a non-RSVP enabled IP network. In such cases, some “interworking” mechanisms between such different technologies and protocols are needed to make sure that the QoS is provided end-to-end.
Integrated Services (IntServ) provides a set of well-defined services which enables an application to choose among multiple, controlled levels of delivery service for its data packets. To support this capability, two things are required. First, individual network elements, such as subnets and IP routers, along the path followed by an application's data packets must support mechanisms to control the quality of service delivered to those packets. Second, a way to communicate the application's requirements to network elements along the path and to convey QoS management information between network elements and the application must be provided.
IntServ defines a number of services such as Controlled-Load (defined in IETF RFC 2211) and Guaranteed (defined in IETF RFC 2212). The service definition sets forth the required characteristics of the network equipment in order to deliver the service. The individual network elements (subnets and IP routers) that support the service must comply with the definitions defined for the service.
The service definition also defines the information that must be provided across the network in order to establish the service. This function may be provided in a number of ways, but it is frequently implemented by the resource reservation setup protocol RSVP (defined in IETF RFC 2205). RSVP (Resource reSerVation Protocol) is an IP-level resource reservation setup protocol designed for an IntServ-enabled Internet (defined in IETF RFC 1633, 2205, and 2210). The RSVP protocol is used by a local host (e.g., User A's computer) to request a specific quality of service from the network for particular application data streams or flows along the data path between sender and receiver. RSVP is also used by routers to deliver quality-of-service request to all nodes along the path(s) of the flows and to establish and maintain the state(s) to provide the requested service. RSVP request generally result in resources being reserved in each node along the data path.
FIG. 2 shows an End-to-End Integrated Service between the hosts. The service is provided using routers and hosts that support the service definition defined for the required service and through signaling of the relevant information between the nodes. In order to use RSVP, each of the devices in the path between the sender and receiver must be capable of understanding and sending RSVP messages. However, some end devices may not be RSVP-enabled, and therefore, can not use RSVP to reserve bandwith or other quality of service characteristics. An RSVP “proxy” can be defined to solve this problem by emulating an RSVP sender or receiver on behalf of such devices. More generally, a proxy is a network device, such as a router or a switch, that performs one or more functions on behalf of another device. As applied to RSVP, and RSVP Proxy originates the RSVP PATH message and receives the incoming RESV message on behalf of a non-RSVP enabled node. (PATH and RESV are examples of RSVP messages.) It also receives an incoming PATH message and originates the RESV response message on behalf of a non-RSVP enabled node. In other words, the RSVP Proxy acts on behalf of the non-RSVP enabled node to facilitate resource reservation without that node having to be involved in the RSVP signaling.
The problem addressed here is how to establish a protocol proxy relationship in a multimedia session involving a mobile communications access network and a non-enabled mobile terminal. A mechanism is provided that allows the non-enabled mobile terminal to communicate a protocol proxy request with an enabled node along the send-receive path between the mobile terminal and a remote host. A mechanism is further provided to install information in the enabled node so that the node can function as the protocol proxy for the non-enabled mobile host.
In setting up a multimedia session between the mobile terminal and the remote host by way of an access point coupled to a packet data network, the mobile terminal sends a request message associated with the multimedia session to the access point. The message request a packet access bearer between the mobile terminal and the access point. The mobile terminal sets an indicator in the request message to indicate that the access point should function as a communications protocol proxy for the mobile terminal for the multimedia session.
From the perspective of the access point, the received request message is asking for a packet access bearer between the mobile terminal and the access point for the multimedia session. Detecting the indicator in the request message means that the access point should function as a communications protocol proxy for the mobile terminal for the multimedia session. Accordingly, the access point performs as the communications protocol proxy for the mobile terminal for the multimedia session.
In one non-limiting example, the request message indicates a particular Quality of Service (QoS), and the communications protocol is the resource reservation protocol (RSVP). Thus, the access point is an RSVP proxy for the mobile terminal during the multimedia session. The mobile terminal may be a User Equipment (UE) that communicates with a General Packet Radio Service (GPRS) access network by way of a UMTS Terrestrial Radio Access Network (UTRAN). In this context, the access point may be a Gateway GPRS Service Node (GGSN). The request message may be a Packet Data Protocol (PDP) context request message, and the indicator may be an RSVP proxy flag. In one example implementation, the PDP context request message may include the RSVP proxy flag as a PDP configuration option (PCO). When the indicator is set, an RSVP proxy state process for the multimedia session is installed from a multimedia server in the GGSN. Thereafter, the RSVP proxy-GGSN generates an RSVP PATH message directed to the remote host, and in response thereto, receives an RSVP RESV message from the remote host on behalf of the mobile terminal. It also generates an RSVP RESV message in response to a received RSVP PATH message as well as generates/responds to RSVP messages other than PATH and RESV, e.g., RESV cont.
Another aspect of the invention includes a computer-generated data signal embodied in an electrical signal for use in a GPRS/UMTS network. A Packet Data Protocol (PDP) context activation, creation, modification, or update message for establishing or updating a multimedia sessions between a mobile terminal and a remote host includes plural fields of information. In particular, the PDP message includes a PDP configuration options (PCO) field that includes an indicator indicating whether the access point should function as a communications protocol proxy for the mobile terminal for the multimedia session. In one example implementation, the indicator field is included with an authorization token and a media binding token associated with the multimedia session.